1. The Field of the Invention
The present invention relates to network technology; and more specifically, to mechanisms for performing role-based authorization of requested network services by correlating roles to security tokens associated with the request regardless of its security token type, and then later authorizing the requested services using the correlated role(s).
2. Background and Related Art
Computing technology has transformed the way we work and play. Computing systems now take a wide variety of forms including desktop computers, laptop computers, tablet PCs, Personal Digital Assistants (PDAs), household devices and the like. In its most basic form, a computing system includes system memory and one or more processors. Software in the system memory may be executed by the processor to direct the other hardware of the computing system to perform desired functions.
Networking technologies enable computing systems to communicate even over vast distances, thereby expanding on computer functionality. For example, networking technologies enable such applications as e-mail, web browsing, file transfer, instant messaging, electronic whiteboarding, network collaboration, and the like. Accordingly, computer networks enable widespread communication and information access.
Unfortunately, computer networks also can potentially open up connected computing systems to security breaches. One type of security breach is for one computing system or user to make false claims about who they are to thereby access network resources they should not have access to. Another security breach is referred to as “eavesdropping” by which an eavesdropper computing system accesses the content of a network communication even though the eavesdropper is an unintended and unwanted party in the communication. In addition, an eavesdropper or other entity might alter the network communication on its way to its intended destination. Any of these security breaches can be quite harmful.
In order to guard against these security breaches, a variety of security technologies have been developed. These technologies are based upon the use of security tokens. Security tokens may be used to authenticate a provider of the security token. In this manner, the security token is the comparable in the electronic domain to a passport or driver's license in the physical domain. Proper authentication provides some level of security that each party to the network communication is indeed who they purport to be. Security tokens may also be used to encrypt all or portions of a network message, thereby preventing eavesdropping by those who do not have access to the security token. Furthermore, security tokens may be used to sign portions of an electronic message to thereby allow those validating this signed portion to determine if the electronic message has been changed since the time it was signed. Authentication, encryption, and electronic signing thus provide some protection against security breaches in network communications.
Network communications increasingly extend beyond transport-level barriers. For example, a Simple Object Access Protocol (SOAP) envelope may be transmitted from one computing system to even while traveling through several transport domains. This is referred to as SOAP tunneling. A HyperText Transport Protocol (HTTP) computing system may transmit a SOAP envelope within an HTTP message to another HTTP computing system. Along the way, however, the SOAP envelope may be placed in other messages that follow different transport protocols, such as, for example, Message Queues (MQ), Simple Mail Transport Protocol (SMTP), CORBA/IIOP, or the like.
While transport-independent network messaging allows for great flexibility in communication, conventional security mechanisms are transport-dependent. End-to-end message level security across multiple transports requires additional technology. Conventional end-to-end security across multiple transport domains has been provided in the form of the Web Services (WS)-Security specification.
The WS-Security Specification only expressly addresses the use of specific security tokens such as, for example, user name token with user name and password, X.509 certificates, Kerberos tokens, and others. However, the number of types of security tokens available for use in authentication, encryption, and electronic signing is rapidly expanding. Accordingly, what would be advantageous is a mechanism for managing security tokens that is extensible to a variety of different security token types, and which is compatible with transport-independent networking technologies such as SOAP.
As a separate issue from the security services described above, it is often desirable to authorize requested service. The security services described above merely provide some assurance through authentication that the service requestor is who they purport to be, some assurance through encryption that the message has not been eavesdropped on, and some assurance through signing that the message has not been altered. However, these security services do not ensure that the authenticated identity has the right to access the service.
In order to provide proper authorization, there is typically a layer of processing needed in order to authorize, separate and apart from authentication. This processing usually relies on some expression of authorization for each service. One way of expressing authorization for a given service is to list all identities that have authority to obtain the service. This can be quite cumbersome when there are numerous identities that have authority to access the service. Another more flexible and less cumbersome way of expressing authorization for a given service is to assign particular identities to one or more roles. A “role” is an expression that may be associated with one or more, and potentially many, identities. The roles, rather than the identities, may then be mapped to specific authorized services.
The following illustrates an example code syntax that enables role-based authentication using ASP.NET. The example code access the HttpContext object to check membership with a Windows user group or Active Directory group.
[WebMethod]
public void AuthorizeOrder(long orderID){if (! HttpContext.Current.User.IsInRole(@“DOMAIN\Accounting”))throw new Exception(“Only members of ‘Accounting’ may call this method.”);// . . . update the database}
In the following example, users in the role “HR” might call the method, but only members of the role “PointyHairedBoss” might set a salary higher than a certain amount:
public void SetMonthlySalary(long employeeID, double salary){if (! HttpContext.Current.User.IsInRole(@“DOMAIN\HR”))throw new Exception(“Only members of ‘HR’ may call this method.”);if (salary > 2000){if (! HttpContext.Current.User.IsInRole(@“DOMAIN\PointyHairedBoss”))throw new Exception(“Only pointy haired bosses may set salaries larger than 2K”);}// . . . update the database}
The code shown above relies on standard ASP.NET. However, this does not enable end-to-end authentication or authorization because it relies upon HTTP authentication.
Accordingly, what would be further desired is an authorization mechanism that does not rely on any specific authentication mechanism and that is flexible across different security token types to thereby enable fine-grained authorization in conjunction with end-to-end authentication.